Given the ubiquitous nature of mobile electronic devices such as, for example, mobile communication devices like cellular telephones, many people are utilizing an expanding variety of applications that are executable at such mobile electronic devices. For example, applications for providing services related to communications, media sharing, information gathering, education, gaming, and many others have been developed, fueled by consumer demand. One particular area in which consumer demand has triggered an expansion of services relates to provision of services related to managing the establishment of communications with, for example, users of other mobile electronic devices. For example, a communication session may be established between various client devices via a network server. Protocols which may be used in such communication sessions may include, for example, Session Initiation Protocol (SIP), Motorola Push-to-Talk (M-PTT) protocol, and the like.
SIP is an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. SIP is widely used as a signaling protocol for Voice over Internet Protocol (VoIP) and media sharing applications. SIP is addressing neutral, with addresses expressed as a uniform resource locator (URL), a uniform resource identifier (URI), a telephone number, an email like address, or the like. SIP is generally considered to be lightweight since it has a limited number of methods to reduce complexity, and transport-independent since it can be used with User Datagram Protocol (UDP), Transport Control Protocol (TCP) and other transport protocols.
M-PTT is an example of a SIP based protocol which may be employed for session based communications such as push-to-talk (PTT) communications. M-PTT signaling messages are text based messages which may be used to set up calls from one network node (e.g., a mobile terminal such as a mobile phone) to another. For example, M-PTT or another session based protocol may be used to set up a PTT call between two network nodes that have subscribed to a PTT service.
Some services provided to network subscribers or users may relate to the establishment of easily accessible lists of contact information, which are commonly known as buddy lists. A buddy list may store one or more contact names and associated contact information which may be utilized to establish communication with the associated contact. In various exemplary embodiments, a buddy list could include contact information for selected ones among fellow subscribers to a service or members of a group which may be defined by the user. A buddy list could be associated with a particular application, such as a buddy list for PTT, a buddy list for email, a buddy list for instant messaging, a buddy list for making phone calls, etc., or the buddy list could be a general listing of contacts by name in which each contact may be associated with one or more particular different applications as indicated by the corresponding stored contact information. A buddy list may also be configured to provide presence information to the user regarding individual and/or group contacts in the buddy list.
Buddy lists are often provided at a size that is governed on a per-system basis. In other words, in a communication network providing PTT services, in which the network may include a PTT server configured to support communications between numerous PTT clients, the PIT server is typically configured to provide buddy list sizes to various clients based on the smallest buddy list size supported by any commercial client in the system. For example, if a first client can support a buddy list size of 100 individual contacts and 50 contact groups and a second client can support a buddy list size of 200 individual contacts and 30 contact groups, the server may only support 100 individual contacts (i.e., the lesser of the individual contact capabilities of the first and second clients) and 30 groups (i.e., the lesser of the contact group sizes supported by the first and second clients). Thus, neither the first client nor the second client can take advantage of its corresponding buddy list size capabilities.
In general, the PTT server may be capable of supporting the largest from among the individual client buddy list sizes. However, given the current fixed-size buddy list approach in which the fixed-size is determined as described above, service providers typically do not provide different grades of service with respect to buddy list size and device capabilities are not able to be fully utilized on a consistent basis.
Accordingly, it may be desirable to provide a mechanism by which to address at least some of the problems described above.